But why are there no bytesright? It parses slightly awkward to me, but that might just be my foreignspeakerness.
bytesremaining or bytesavailable seem more natural for me.

bytesleft also does not quite have the right connotations, since it's not the number of bytes left in the stream, rather it's the number of bytes available right now in the buffer.

How about bytesavailable then?

How about nbytesbuffered? (nb was non-blocking, but more clearly may have been nbuffered)

bytesavailable looks like returning buffered bytes. I think n prefix is needed here.

The PR now does bytesavailable. It has a nice symmetry with readavailable. I left off the n because nbytesavailable seems like quite a mouthful to me.

I like the name. I still dislike the function, but given that it exists, this is a good name.

I don't really like calling it "available" for the same reason I think the name "readavailable" is too confusing. These functions are defining that available means "buffered for instant, non-blocking access", but I think that seems hardly an intuitive definition.

but I think that seems hardly an intuitive definition.

What the heck else would it mean?

Bytes-transmitted (streams) or bytes-remaining (Files)

I still think n prefixing is important here because it doesn't return buffered bytes themselves. n prefixing is a common practice in Base (e.g. ncodeunits, ndigits, ndims, nfields). I don't think just a bit mouthful name would not be a good reason to break the rule.

Fair point, @bicycle1885. I've opened #25659.

Would be good to have Compat support for bytesavailable...